The document class used in the process documents is CoreDocument. Its full name is com.axemble.vdp.ui.core.document.CoreDocument.
As the class AbstractDocument, this one remembers a fields list corresponding to the fields described in the administration forms. It is the Java representer of form data presented to the final user.
This class, dynamic and abstract notion representing the stored data in base, mainly enables to dynamically modify the process document fields values without forcing the physical storage in database. In fact, a series of actions can be run on the class without altering the data in any way.
It permits also to find dynamic information such as the current step or task, the connected user, the parent document (case of dynamic tables) and the back office objects too. However, these informations can be accessed from the SDK API and the navigation.
Main methods of the CoreDocument class
| Method | Description |
| public boolean isCreationMode() | This state lets you know whether the document being loaded will be created or not. |
| public boolean isLoading() | This state indicates whether or not the document is being loaded. |
| public boolean isModified | This state indicates whether the document was modified |
| public IFieldControl getMainControlByPropertyName( String name ) | Finds the main graphic control (often in edit mode) corresponding to a given property. |
| public ICoreField getFieldByName( String name ) | Finds the CoreField object through the property's system name. |
| public Collection getFields() | Finds all the CoreField objects active on the document. |
| public void saveToResource | Saves the document. The data will be stored in the database. |
| public CoreDocument getParentDocument | Finds the parent document in case of dynamic table of the "linked documents" type |
| public ServiceManager getServiceManager | Finds the service object that allows access to all other managers and services. |
| public User getUser() | Finds the connected user |
| public Catalog getCatalog() | Finds the current catalog. |
| public ResourceTemplate getResourceTemplate() | Finds the resource template associated with the document. |
| public Treatment getTreatment() | Finds the back-office object representing the document in the database |
| public Resource getResource() | Finds the back-office object representing all the document values. |
| public ManualActivity getActivity() | Finds the active step of the document (access in intervention mode) |
| public String getStageName() | Finds the system name of the document's active step |
| public String getStoragePath() | Returns the root directory of component descriptors and their associated graphic interface. |
Simplified diagram of the CoreDocument class
The following diagram displays the existing links between the couples (AbstractDocument, AbstractField) and (CoreDocument, CoreField).
This diagram identifies two document categories:
VDoc fully use this document class to manage subscriptions between fields and every Java (extensions) or Java Script code openings.
The CoreDocument link is linked to fields composed of graphical components and a CoreField class that control the handled value.
The document fields implements the IFieldControl interface. For the ones which manage several values (ex.directory multiple selectors): they implement the IFieldListControl interface.
Principle schema between the linked objects
It exists an events wiring between the CoreField (the value) and the assigned graphical components. Indeed, if a field value is modified through the CoreDocument object, all the graphic components will be refreshed. On the other hand, if a user modifies the value of a field (from the interface), the latter will trigger an event that will update CoreField and then the other associated graphic components.
Events mechanism between the linked objects
This entire mechanism is managed in VDoc. It is applicable for fields subscriptions but also while running the extensions. This mechanism is put on the basic elements; AbstractDocument and AbstractField, and the GenericDocument class receives this event mechanism too.
The CoreField class is an abstract representation of the document's field value. It implements the ICoreField interface. The aim of this class is to de-link the value of each document field from its graphical aspect. In fact, based on its design at the Web Designer level, a field can appear multiple times in the document (in multiple sections). The value can be represented differently (ex. in simple text form in a section in read mode, in the form of a list in the intervention section).
The ICoreField interface
public interface ICoreField
{
public boolean loadFromResource();
public boolean loadFromAnotherDocument(CoreDocument srcDocument);
public boolean saveToResource();
public boolean isModified();
public Property getProperty();
public String getPropertyName();
public boolean setValue(Object value);
public boolean setValue(Object value, Object changeSource);
public Object getValue();
public boolean equalsValue(Object valueToCompare);
public CoreDocument getDocument();
public void release();
public void setList(Collection values, Object changeSource);
public Collection getList();
}